Simulate Static Deposit (Sandbox)

In sandbox, a deposit to one of the account's static deposit details is simulated with one API call: you say which detail received money, how much and, optionally, who sent it. The deposit then goes through the same processing as in production. Avenia creates the ticket, converts the amount to USDC, credits the INTERNAL balance and sends the ticket webhooks, exactly as it would for a real transfer.

It works for every static deposit detail:

`currency`	`paymentMethod`	Detail in Account Info	What it simulates
`MXN`	`CLABE`	`clabe`	A Mexican bank transfer to the account's CLABE
`ARS`	`CVU`	`cvu`	An Argentine transfer to the account's CVU
`COP`	`BRE-B`	`bre-b`	A Bre-B payment to the account's key
`USD`	`SWIFT`	`swiftReceivingAccount`	A SWIFT transfer to the account's receiving account

info

This endpoint exists only in sandbox. In production the deposit comes from a real transfer to the same detail, and the same ticket, webhooks and credit follow.

Before you start

The account needs the detail you want to simulate. GET /v2/account/account-info shows it:

clabe, cvu and bre-b show up once the account's KYC or KYB for that currency is approved.
swiftReceivingAccount shows up once Avenia enables SWIFT deposits for the account. Ask your account manager to enable them for your sandbox account.

See Get the Static Deposit Details.

1. Read the details

cURL
curl -X GET "https://api.sandbox.avenia.io:10952/v2/account/account-info" \
  -H "Authorization: Bearer eyJhdXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

JSON
{
  "clabe": "999999000012345678",
  "cvu": "0009999000001234567890",
  "bre-b": "@SBX000000001234",
  "swiftReceivingAccount": {
    "beneficiaryName": "Jane Doe",
    "bankName": "Sandbox Bank",
    "bic": "SBXXUS33XXX",
    "accountNumber": "9999000123456789",
    "routingNumber": "999999999",
    "bankAddress": {
      "street1": "1 Sandbox Plaza",
      "street2": "",
      "city": "New York",
      "region": "NY",
      "postalCode": "10001",
      "country": "US"
    }
  }
}

In sandbox these are test details no real bank can pay. Show them the way you will show the real ones in production.

2. Simulate the deposit

POSThttps://api.sandbox.avenia.io:10952/v2/account/sandbox/static-deposits

The deposit always lands on the account's own detail for that currency: you don't send the detail itself.

Parameters

Field	In	Type	Description
`subAccountId`	query	string	Optional. The sub-account that receives the deposit. Omit it for the main account.

Body

Field	Type	Required	Applies to	Description
`currency`	string	Yes	All	`MXN`, `ARS`, `COP` or `USD`.
`paymentMethod`	string	No	All	`CLABE`, `CVU`, `BRE-B` or `SWIFT`. Defaults to the currency's method in the table above.
`amount`	string	Yes	All	The amount that arrives, in `currency`, as a decimal string with at most two decimals, such as `"150.00"`.
`senderName`	string	No	All	The sender's name. For `USD`, omit it for a transfer from the account holder.
`senderTaxId`	string	No	MXN, ARS, COP	The sender's tax ID, such as a CUIT for ARS.
`senderAccountNumber`	string	No	All	The account the money came from: a CBU or CVU for ARS, an account number or IBAN for USD. An ARS deposit that is not credited is sent back to it, as in production.
`senderType`	string	No	USD	`individual` or `business`. Defaults to `individual`.
`senderBankName`	string	No	USD	The sender's bank.
`senderBic`	string	No	USD	The sender's bank BIC.
`paymentReference`	string	No	USD	The reference the sender wrote on the transfer.

Fields that don't apply to the currency are ignored.

Request examples

MXN to the CLABE:

cURL
curl -X POST "https://api.sandbox.avenia.io:10952/v2/account/sandbox/static-deposits" \
  -H "Authorization: Bearer eyJhdXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" \
  -H "Content-Type: application/json" \
  -d '{
    "currency": "MXN",
    "amount": "1000.00"
  }'

USD by SWIFT:

cURL
curl -X POST "https://api.sandbox.avenia.io:10952/v2/account/sandbox/static-deposits" \
  -H "Authorization: Bearer eyJhdXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" \
  -H "Content-Type: application/json" \
  -d '{
    "currency": "USD",
    "amount": "150.00",
    "senderBankName": "Example Bank",
    "paymentReference": "INVOICE-1042"
  }'

Response

202 Accepted. The deposit is processed in the background.

JSON
{
  "id": "sbx-3f1c2a7e-5b8d-4e6f-9a0b-1c2d3e4f5a6b",
  "externalId": "mxn-deposit-sbx-3f1c2a7e-5b8d-4e6f-9a0b-1c2d3e4f5a6b"
}

id is the simulated deposit. Every call is a new deposit: calling twice simulates two deposits.
externalId is the externalId of the ticket Avenia creates for it.

3. Follow the ticket

Avenia creates the deposit's ticket by itself within seconds of the call, and you receive its webhooks as for a real deposit. See Webhook Events and When Avenia asks for the code afterwards.

For every currency these are DEPOSIT-PROCESSING, DEPOSIT-SUCCESS, DELIVERY-PROCESSING, DELIVERY-SUCCESS, TICKET-PURPOSE-CODE-REQUIRED and TICKET-COMPLETE. They can arrive in a different order.

To find the ticket without a webhook, list the tickets by the externalId the call returned:

cURL
curl -X GET "https://api.sandbox.avenia.io:10952/v2/account/tickets/?externalId=mxn-deposit-sbx-3f1c2a7e-5b8d-4e6f-9a0b-1c2d3e4f5a6b" \
  -H "Authorization: Bearer eyJhdXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

The ticket has the deposit's currency and payment method as input, outputCurrency USDC and outputPaymentMethod INTERNAL, and ends PAID with the USDC credited to the account's INTERNAL balance.

Simulating a third-party SWIFT sender

For USD, send a senderName that is not the account holder's name to simulate a transfer from someone else:

cURL
curl -X POST "https://api.sandbox.avenia.io:10952/v2/account/sandbox/static-deposits" \
  -H "Authorization: Bearer eyJhdXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" \
  -H "Content-Type: application/json" \
  -d '{
    "currency": "USD",
    "amount": "80.00",
    "senderName": "Example Trading Inc",
    "senderType": "business",
    "senderBic": "EXAMPLEXXXX"
  }'

It is a third-party deposit and is priced as one. When the account doesn't accept third-party deposits, it is held for compliance review instead of being credited, as in production. See USD by SWIFT.

Errors

The call is checked before anything is processed:

Status	Message	Meaning
`400`	`CLABE deposits are not enabled for this account`	The account has no `clabe` yet. The same message names `CVU`, `BRE-B` or `SWIFT` for the other details. See Before you start.
`400`	`InvalidFieldError: currency is invalid`	`currency` is missing or is not `MXN`, `ARS`, `COP` or `USD`.
`400`	`InvalidFieldError: paymentMethod is invalid`	`paymentMethod` is not the currency's method, for example `CVU` with `MXN`.
`400`	`InvalidFieldError: amount is invalid`	The amount is missing, not a number, not positive, or has more than two decimals.
`400`	`InvalidFieldError: senderType is invalid`	For `USD`, `senderType` is neither `individual` nor `business`.
`404`	`NotFoundError: subAccountId not found`	`subAccountId` is not a sub-account of yours.

What is not simulated

These behave exactly as in production:

The account's limits: a deposit over the monthly fiat-in limit for its currency is not credited. See Limits.
The fees and the quote of the conversion to USDC. A deposit that doesn't cover the fees of its currency and method, such as a SWIFT deposit smaller than the SWIFT fee, is not credited and gets no ticket.
For USD, the comparison of the sender with the account holder.

If any of these return an unexpected result in sandbox, it reflects a real behavior, not the simulation.

Before you start​

1. Read the details​

2. Simulate the deposit​

Parameters​

Body​

Request examples​

Response​

3. Follow the ticket​

Simulating a third-party SWIFT sender​

Errors​

What is not simulated​